Description of the Prior Art
Object-based computing systems, in particular distributed object computing systems, are increasingly being adopted as an effective means of enabling business information systems to respond more rapidly to changes in business needs. This is achieved today by making available programs and sub-programs as components in an object-based computing system, and manually configuring those components into applications.
Increasingly powerful desktop computers can provide graphical human-computer interfaces for access to applications modelled on the real world. Business information applications running on the desktop computers typically need to collaborate with programs running on shared `server` computers. The server computers may be microprocessor-based systems, or alternatively minicomputer or mainframe computer systems.
The advent of object-based computing systems provides a possibility for reusability of components in complex applications like business information applications. Before the use of object-based systems, complex applications were typically based on purpose-built collections of cooperating modules or components which were constructed with little thought to their reusability.
The use of proprietary protocols for messages exchanged between components and the lack of standards for describing the format and meaning of arguments passed between the components typically meant that components were poorly optimised for reuse. The result of the poor optimisation for reuse is that the creation of new applications built of such components takes considerable time due to the necessity to create the "glue" for connecting those components.
There is considerable pressure on application developers to reduce the application development cycle time from the identification of needs to the delivery of a solution. Assembling applications from reusable components offers the potential to reduce this cycle time.
A number of proprietary computing environments and systems allow components to be made available as "black boxes" to the rest of the computing environment. Examples of this are the Object Linking and Embedding (OLE) environment from Microsoft Corporation (OLE is a trademark of Microsoft Corporation), the Distributed System Object Model (DSOM) environment from IBM Corporation, the Common Object Request Broker Architecture (CORBA) specification managed by the Object Management Group (OMG) and the Arranger environment from Texas Instruments Software. Details of the OLE environment can be found in "Inside OLE", 2nd Edition by K Brockschmidt published in 1995 by Microsoft Press ISBN 1-55615-843-2. Details of CORBA can be found in "CORBA Services: Common Object Server Specification", Revised Edition, Mar. 31, 1995, OMG Document Number 95-3-31.
The environmental system provides a standard way to define a component so that other components or applications within the computing environment may be assembled to use the services (or features) of any other component. A component is defined here as an executable module which implements a useful, clearly defined unit of functionality and provides a well defined interface such that the details of its underlying implementation are not visible externally. A component may be used a part of another component, used in the provision of applications, or used directly by the end user of the computing environment.
FIG. 1 of the accompanying drawings shows an example of an application 10 assembled from two components 12 and 14. A first component 12 supplies a list of customers and the second component provides a list of orders for a particular customer. To build this application, the designer needs to find the desired components, represent the desired components in a user interface and provide a way for a chosen customer from the customer component 12 to be supplied to the list order service of the order component 14.
As mentioned above, a mechanism for providing support for the concept of a component in such environments is the use of an object-oriented model. Under this model, objects implement components and the operations of an object implement the services of a component. Thus the process of assembling components is actually achieved through the use of objects and their operations.
The Arranger product mentioned above provided a significant step towards a reduction in application development cycle times by providing an infrastructure for supplying components ready for assembly. However, the process of assembling components into end applications remains a largely manual process. As has been illustrated with reference to FIG. 1, the application designer needs to:
identify the components of interest; PA1 write program code that defines how each component will be used by the application including describing how information received from one component will be used by another component; and PA1 represent information from components to the end user of the application through the use of software routines and the provision of a graphical user interface. PA1 clears related information when specified operations are run (eg, clearing the customer details displayed in the user interface if another customer is selected); PA1 reset related information (by running other operation(s)) when specified operations are run (for example running the "List Orders" operation if another customer is selected); PA1 get further information about a particular object by running another operation (for example running the "Customer Details" operation whenever a customer is selected); and PA1 update information about a particular object by running another operation (eg, running the "Update Customer" operation whenever a customer value is changed). PA1 (a) automatically to create application views when requested; PA1 (b) automatically to map input parameter values to an operation, for a given operation usage, from one or more application views when a user requests an operation usage to be triggered; PA1 (c) automatically to map output parameter values from an operation to one or more application views for an operation usage, when the operation usage has been completed; PA1 (d) to manage effects of operation usages on application views and trigger any associated application view events; PA1 (e) to manage effects of application view events on application views and trigger any associated operations; PA1 (f) to determine what operation usage(s) can be run on the basis of input parameter satisfaction. PA1 i) generating a declarative user input interface mechanism providing an input structure for inputting user declarations specifying operative interactions between component objects; and PA1 ii) automatically generating, in response to input user declarations, an application design definition modelling an application infrastructure for managing component object interactions. PA1 responding at runtime to an application design definition, which models an application infrastructure for managing component object interactions automatically to create application view instances from respective application view definitions for managing runtime component object interactions for the application. PA1 causing an application engine to create application view instances from respective application view definitions of the application design definition; PA1 displaying values held in the application view instances; and PA1 permitting operations to be invoked.
In the object-oriented model, objects provide access to objects via units of software functionality, usually referred to as operations or methods. An operation is generally thought of as having two parts, namely an external definition and an internal implementation.
The internal implementation is specified as algorithms or rules and turned into an executing unit via suitable tools. The algorithm may act on the particular object to which the operation belongs and may also invoke any operation of any other object within the scope of the system, subject to any constraints of the system.
However, to a client which requires access to a component object, the internal implementation is of little interest. Indeed, it is often only physically present in the computing environment as compiled computer code. In contrast, a client which requires access to an operation would have at least some part of the external definition of the operation available. The mechanism varies with the object system, but at some level it is possible to discover how the operation is invoked and what it does.
The external definition of an operation, of a specific object, may also include the object to which it applies, and may also include a number of additional parameters or argument definitions. Typically, the parameters are defined in the formal syntax of the object system. Other defined information may also be available such as non-formal descriptions of the parameters, formal and non-formal descriptions of the operation, formal and non-formal precondition information. FIG. 2 of the accompanying drawings is a schematic representation of this.
Parameters define elements which will either be used (inputs), returned (outputs), or used and returned (inputs and outputs) by the operation. In general, the definition of parameters is limited only by the scope of the system, i.e, a parameter can potentially be any object or data type value within the scope of the system.
For example, suppose an operation to return information about the "Orders a Customer has Placed" is required. This could be defined as an operation called, say "List Orders for Customer", for which the customer is a required input parameter, and for which outputs include a list of orders, a count of the total number of orders and the last order fulfilled. FIG. 3 of the accompanying drawings is a schematic representation of this.
To carry out some user task or function in an application which utilises a component object system, the use of one or more operations is required, often from different objects (components). In most cases, for the task to be achieved, information output by one operation is required as input to another operation to achieve some overall effect. For example, with reference to FIG. 4 of the accompanying drawings, a "List Orders for Customer" operation 20 might also be used in conjunction with a "List Customers" operation 22, a "Customer Details" operation 24, an "Add New Order for Customer" operation 26, and a "Total Invoice for Customer" operation 28.
Given such a set of operations, application designers typically write computer algorithms (the `glue` between operations) to carry out the flows or information or information mappings as part of the process of assembling a new component or application. In addition, the designer must ensure that required input information is available in the right format for an operation to run successfully. For example, a "List Orders for Customer" operation 20 might require a single "Customer ID" as an integer data type, but a "List Customers" operation 22 may supply a list of values as string data types. FIG. 4 illustrates this glue as flow lines having arrow heads between operations. When the application is run, information is passed along the flow lines in accordance with the defined algorithms.
Apart from ensuring an accurate mapping of information between relevant operations, the designer also needs to provide a user interface for the end user to have an understanding of and to be able to interact with the component objects being used by the application.
In addition to writing computer algorithms to pass information between the operations, the designer will normally use some internal, intermediate representation of the information encompassed within the scope of that set of operations. Frequently, the designer will use language or environment features such as variables, arrays or collections to organise these intermediate representations. Part or all of these representations are typically translated to the human-computer interface to provide the user with an understanding of the state of the objects and to allow the user to interact with the objects. FIG. 5 of the accompanying drawings illustrates this as arrowhead lines between the operations identified in FIG. 4 and a user interface 30. For example, the designer may define algorithms to present the list of customers returned by the "List Customers" operation 22 in the computer user interface and translate the user interface representation of the chosen customer into the input parameters of the "List Orders for Customer" operation 20. The outputs of this operation will in turn be presented in the computer user interface.
When considering user interface representations, the designer must also comprehend and provide a mechanism for managing the interaction of related information from operations. For example, in an application which shows a list of customers and a list of orders for a customer, if the end user changes, the selected customer of the application should refresh the list of orders by running a suitable operation.
In general, therefore, the designer must provide a mechanism which:
It will be appreciated from the above that the development of new applications, even using components which are ready for assembly, is a complex task requiring significant software development times by skilled engineers.
Accordingly, an aim of the invention is to provide a mechanism which will enable application development times to be further reduced. In particular, an aim of the invention is to facilitate the generation of applications from component objects.